Summary of Changes

Hello @filipecaixeta, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves a critical DataError in PostgreSQL by implementing consistent timezone stripping for timestamps, mirroring the existing behavior for SQLite to accommodate PostgreSQL's TIMESTAMP WITHOUT TIME ZONE type. Concurrently, it enhances the A2A to GenAI part conversion mechanism by introducing and supporting a new thought metadata field across various part types, enabling richer contextual data transfer.

Highlights

• PostgreSQL Timestamp Fix: Addressed a 'DataError: can't subtract offset-naive and offset-aware datetimes' that occurred when using PostgreSQL with asyncpg. This error stemmed from attempting to store timezone-aware datetime objects into PostgreSQL's default TIMESTAMP WITHOUT TIME ZONE column type.
• Consistent Timezone Stripping: Extended the existing timezone stripping logic, previously applied only to SQLite, to now also include PostgreSQL. This ensures that datetime.now(timezone.utc) objects are converted to timezone-naive before being stored, aligning with the database's expected format.
• New 'thought' Metadata Support: Introduced a new thought metadata field for various Part types (TextPart, FilePart, FunctionCall, FunctionResponse, CodeExecutionResult, ExecutableCode) during the conversion process between A2A and GenAI formats. This allows for the propagation of additional contextual information.
• Expanded Unit Tests for 'thought' Metadata: Added comprehensive unit tests to validate the correct handling and round-trip conversion of the new thought metadata across all supported Part types, ensuring data integrity during format transformations.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Response from ADK Triaging Agent

Hello @filipecaixeta, thank you for creating this PR!

This PR is a bug fix. Could you please associate the GitHub issue with this PR? If there is no existing issue, could you please create one?

In addition, could you please provide logs or a screenshot after the fix is applied?

This information will help reviewers to review your PR more efficiently. Thanks!

Hi @filipecaixeta , Thank you for your contribution! We appreciate you taking the time to submit this pull request.

/gemini review

Hi, thanks for this fix — we hit the exact same issue with asyncpg + PostgreSQL.

One thing worth noting: while this PR fixes the create_session path, there's a related timezone semantic inconsistency in append_event (around line 516-521):

if is_sqlite:
    update_time = datetime.fromtimestamp(
        event.timestamp, timezone.utc
    ).replace(tzinfo=None)
else:
    update_time = datetime.fromtimestamp(event.timestamp)

The else branch (which covers PostgreSQL) uses datetime.fromtimestamp(event.timestamp) without a timezone argument, so it produces a naive datetime in the local timezone. The SQLite branch produces a naive datetime in UTC.

This doesn't cause an asyncpg error (since the result is already naive), but it means the same event.timestamp gets stored as different wall-clock values depending on the database backend — and on the server's local timezone. On a non-UTC server:

• SQLite: stores 2026-02-06 06:48:16 (UTC)
• PostgreSQL: stores 2026-02-06 14:48:16 (local, e.g. UTC+8)

The create_session path (which this PR fixes) had the same kind of issue — datetime.now(timezone.utc) produces UTC, so after .replace(tzinfo=None) the stored value is UTC-based. It might be worth making append_event consistent too:

# Consistent UTC for all backends
update_time = datetime.fromtimestamp(event.timestamp, timezone.utc)
if self.db_engine.dialect.name in ("sqlite", "postgresql"):
    update_time = update_time.replace(tzinfo=None)

Hi @filipecaixeta.

I have a related PR #4388 that takes a different approach fixing this at the schema level by using postgresql.TIMESTAMP(timezone=True) in PreciseTimestamp.load_dialect_impl()

I'd like to share some analysis on why I think stripping timezone (replace(tzinfo=None)) may not be sufficient for PostgreSQL, and why a schema-level fix might be more appropriate

The append_event inconsistency

As @rusherman also pointed out, there's a semantic inconsistency in append_event

if is_sqlite:
    update_time = datetime.fromtimestamp(
        event.timestamp, timezone.utc
    ).replace(tzinfo=None)
else:
    update_time = datetime.fromtimestamp(event.timestamp)  # uses LOCAL timezone

For the else branch (PostgreSQL/MySQL):

• datetime.fromtimestamp(event.timestamp) return a naive datetime in the app server's local timezone
• This gets stored as-is into a TIMESTAMP WITHOUT TIME ZONE column
• If the app server is in PDT (UTC-7) and the DB server is in UTC, the stored value is off by 7 hours

This is exactly the bug described in #1848

Why replace(tzinfo=None) doesn't fully solve this?

Even if we add replace(tzinfo=None) for PostgreSQL in create_session, the append_event path still uses datetime.fromtimestamp(event.timestamp) which produces local-timezone naive datetimes. We'd need to fix that too, and at that point we're stripping timezone info from UTC datetimes just to store them in a timezone-unaware column fighting against the database rather than working with it.

Schema-level approach (PR #4388)

My PR instead makes PreciseTimestamp return postgresql.TIMESTAMP(timezone=True) for PostgreSQL, so the column type is TIMESTAMPTZ. This means:

• create_session: datetime.now(timezone.utc) is stored correctly with timezone info preserved
• append_event: Even naive datetimes are interpreted as the DB server's timezone (typically UTC), which is more predictable than depending on the app server's local timezone
• Reading back: PostgreSQL always returns timezone-aware datetimes, so update_time.timestamp() computes correctly

The tradeoff is that existing PostgreSQL users need a one-time migration

ALTER TABLE sessions ALTER COLUMN create_time TYPE TIMESTAMP WITH TIME ZONE;
-- (and similar for other timestamp columns)

Ideally

The best fix would combine both approaches

1. Schema-level: TIMESTAMP WITH TIME ZONE for PostgreSQL (my PR fix: use TIMESTAMP WITH TIME ZONE for PostgreSQL in PreciseTimestamp #4388)
2. Code-level: Ensure append_event also uses UTC-aware datetimes consistently:

update_time = datetime.fromtimestamp(event.timestamp, timezone.utc)

This way all timestamps are explicitly UTC throughout the entire pipeline, regardless of the app server's timezone.
What do you think? Happy to coordinate on this